(1) Field of the Invention
The invention relates to improving efficiency in computer systems, reducing the use of conditional statements. More specifically, the invention relates to manipulation of protected and unprotected pages to eliminate the need for conditional statements in cases in which one branch of the conditional is rarely or never taken.
(2) Related Art
In many common computer systems, memory is organized into pages. Page protection is common in existing virtual memory systems. Physical memory is divided into pages and allocated among different processes. From the prospective of a process, any particular page can be allocated as unprotected or protected. An unprotected page allows the process to read or write to any address on the page. Among the possible protection schemes are read protection and write protection. As the names imply, a write protected page may be read by the process, but not written to or modified in any way. A read protected page could be written to, but not read. Generally, there is little reason to allow a page to be written but not read. A page that is both read and write protected cannot be either read from or written to by the process. Allocating pages between these levels of protection is well known in the art
Many systems support signal handlers which are code segments executed by the system in response to receipt of an interrupt or exception signal. Such systems provide default signal handlers, but also provide support for replacement of the default signal handler with a user-defined signal handler. Accordingly, custom signal handlers are known in the art.
Two common programming constructs are pointers and conditional statements. A pointer is a variable defined to be an address at which some data resides rather than the data itself. This allows the data associated with the variable to be changed by writing to the address rather than redefining the variable. Defining pointers is well understood in the art.
Conditional statements have been a mainstay of computer programming since its inception. Conditional statements typically involve three parts: the comparison part, the "then part," and the "else part. " The comparison part is always executed, but only one of the "then" and "else" parts is executed. This forces a branch over some part of the code. If the branch is mispredicted, the result is a flush of the pipeline's contents and the corresponding performance loss. Accordingly, branches are performance expensive, and it is desirable to avoid them when possible. A branch target buffer (BTB) has commonly been employed to help reduce this performance loss. However, as a branch target buffer compares the program counter of a previous execution of the conditional statement and the corresponding result, where the code is replicated several times, the BTB will fail to yield the desired performance improvement. Moreover, when a BTB is confronted with a conditional statement executed many times in different code segments, the BTB can become full as it is basically a table of limited size. Once the BTB is full, each new entry replaces an old entry, thus, possibly deleting an entry that would otherwise be used later. Minimizing the number of conditional statements in the code reduces the likelihood that any needed entry will have been displaced from the BTB.
Some conditional statements (or code sequence) are designed to distinguish between a legal or normal occurrence which occurs very frequently, and an illegal or error occurrence which occurs very rarely. FIGS. 1a and 1b show such a conditional statement. FIG. 1a shows a function written in a high level language in which the variable "x" is greater than 3 implies an error has occurred. As long as "x" is not greater than 3, the normal code should be executed sequentially. FIG. 1b shows the assembly code corresponding to the high level code of FIG. 1a The variable "x" is initially compared with 3. A jump in the normal code occurs unless "x" is greater than 3. Here if, for example, the branch prediction assumes not taken, anytime "x" is in the normal range, the branch will be mispredicted and a performance deteriorating pipeline flush will be required. As discussed above, a BTB could remedy this problem, if this were a single code section executed repeatedly. However, where the code segment occurs many times, with no particular conditional statement executed more than once, a BTB fails to improve the performance.
It would be desirable to have a method and apparatus for distinguishing between legal and illegal values without introducing conditional statements into the coding.